<!DOCTYPE html>
<html class="client-nojs vector-feature-language-in-header-enabled vector-feature-language-in-main-page-header-disabled vector-feature-page-tools-pinned-disabled vector-feature-toc-pinned-clientpref-0 vector-toc-not-available vector-feature-main-menu-pinned-disabled vector-feature-limited-width-clientpref-1 vector-feature-limited-width-content-enabled vector-feature-custom-font-size-clientpref-1 vector-feature-appearance-pinned-clientpref-0 skin-theme-clientpref-day vector-sticky-header-enabled" lang="de" dir="ltr"><head>
<meta charset="UTF-8">
<title>Debuggen</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="icon" type="image/png" href="./_res_/favicon.png">
<link rel="canonical" href="https://de.wikipedia.org/wiki/Debuggen"> <link href="./_mw_/ext.cite.styles.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.wikimediamessages.styles.css" rel="stylesheet" type="text/css">
<link href="./_mw_/skins.vector.icons.css" rel="stylesheet" type="text/css">
<link href="./_mw_/skins.vector.search.codex.styles.css" rel="stylesheet" type="text/css">
<link href="./_mw_/skins.vector.styles.css" rel="stylesheet" type="text/css">
<meta name="ResourceLoaderDynamicStyles" content="">
<link href="./_mw_/ext.gadget.citeRef.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.defaultPlainlinks.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.dewikiCommonHide.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.dewikiCommonLayout.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.dewikiCommonStyle.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.dewikiDarkmode.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.dewikiResponsive.css" rel="stylesheet" type="text/css">
<link href="./_mw_/ext.gadget.specialSearch.css" rel="stylesheet" type="text/css">
<link rel="stylesheet" type="text/css" href="./_mw_/site.styles.css">
<link rel="stylesheet" type="text/css" href="./_mw_/noscript.css">
<link rel="stylesheet" type="text/css" href="./_res_/footer.css">
<link rel="stylesheet" type="text/css" href="./_res_/vector-2022.css">
</head>
<body class="skin--responsive skin-vector skin-vector-search-vue mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Debuggen rootpage-Debuggen skin-vector-2022 action-view">
<div class="mw-page-container">
<div class="mw-page-container-inner">
<div class="mw-content-container">
<main id="content" class="mw-body">
<header class="mw-body-header vector-page-titlebar">
<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Debuggen</span></h1>
</header>
<a id="top"></a>
<div id="bodyContent" class="vector-body ve-init-mw-desktopArticleTarget-targetContainer" aria-labelledby="firstHeading" data-mw-ve-target-container="">
<div id="contentSub">
<div id="mw-content-subtitle"></div>
</div>
<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Als <b>Debuggen</b> (dt. Entwanzen)<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> oder <b>Fehlerbehebung</b><sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> bezeichnet man in der Informatik den Vorgang, in einem Computerprogramm Fehler oder unerwartetes Verhalten zu <a href="Fehlerdiagnose" title="Fehlerdiagnose">diagnostizieren</a> und zu beheben.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> Die Suche von Programmfehlern (sogenannten <a href="Softwarefehler" class="mw-redirect" title="Softwarefehler">Bugs</a>) ist eine der wichtigsten und anspruchsvollsten Aufgaben der <a href="Softwareentwicklung" class="mw-redirect" title="Softwareentwicklung">Softwareentwicklung</a> und nimmt einen großen Teil der Entwicklungszeit in Anspruch. Ein guter Programmierer muss daher auch das Debuggen beherrschen und umgekehrt: Nicht jeder gute Programmierer ist auch ein guter Debugger.<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>
</p><p>Die möglichen Ansätze, um Fehler zu finden, sind vielschichtig und hängen vom vorhandenen Problem ab. Es kommen Werkzeuge für interaktives Debuggen (sogenannte <a href="Debugger" title="Debugger">Debugger</a>) zum Einsatz, es werden <a href="Datenflussdiagramm" title="Datenflussdiagramm">Datenflussdiagramme</a> analysiert, <a href="Unittest" class="mw-redirect" title="Unittest">Unittests</a> geschrieben, <a href="Speicherdump" class="mw-redirect" title="Speicherdump">Speicherdumps</a> analysiert und mittels <a href="Profiler_(Programmierung)" title="Profiler (Programmierung)">Profilern</a> die Laufzeit der Programme optimiert.
</p>
<div class="mw-heading mw-heading2"><h2 id="Begriffsherkunft">Begriffsherkunft</h2></div>
<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="Programmfehler" title="Programmfehler">Programmfehler</a></i></div>
<p>Die Begriffe <i>Debuggen</i> und <i>Debugger</i> stammen vom englischen Wort bug, das für „Käfer“ oder „Wanze“ steht, denn die ersten elektronischen Rechenmaschinen mussten tatsächlich von solchem Ungeziefer befreit werden. Der Begriff selber ist aber deutlich älter und taucht bereits im 19. Jahrhundert auf.
</p><p>Der Begriff <i>Debugger</i> kann sowohl das Programm als auch die Person bezeichnen, die diese Tätigkeit ausführt.
</p>
<div class="mw-heading mw-heading2"><h2 id="Umfang">Umfang</h2></div>
<p>Computersysteme und die darauf laufende Software sind nie perfekt. Irgendjemand möchte immer, dass die Software mehr macht, als sie derzeit kann, oder dass sie etwas anders macht als aktuell. Daher muss bei der Meldung oder Beobachtung eines <a href="Programmfehler" title="Programmfehler">Programmfehlers</a> zunächst einmal beurteilt werden, ob und inwieweit das beobachtete Verhalten einen Fehler darstellt und gegebenenfalls mit welcher Methode der Fehler am besten analysiert werden sollte. Aus diesem Grund wird auch oft nicht mehr von „Fehlern“ oder „Bugs“ gesprochen, sondern es werden neutralere Begriffe verwendet, etwa der englische Ausdruck „Issue“ (Aufgabe, Sachverhalt).
</p><p>Der erste Schritt beim Debuggen ist in der Regel, das unerwünschte Verhalten zu reproduzieren. Das kann teilweise bereits ein erhebliches Problem darstellen, etwa wenn der Fehlerbericht – beispielsweise von einem Kunden – ungenau („ich kann mich nicht mehr an die Fehlermeldung erinnern“) oder viel zu allgemein ist („das blöde Programm funktioniert nicht!“). Andere Fehler sind aus technischen Gründen schwer zu reproduzieren, etwa wenn in einer <a href="Multithreading" title="Multithreading">Multithreading</a>-Umgebung der Fehler aufgrund einer zeitlichen Abhängigkeit zwischen zwei <a href="Thread_(Informatik)" title="Thread (Informatik)">Threads</a> nur zufällig auftaucht. Solche Fehler können manchmal verschwinden, wenn man versucht, sie einzugrenzen. Sie werden deswegen auch <a href="Heisenbug" title="Heisenbug">Heisenbugs</a> (nach <a href="Werner_Heisenberg" title="Werner Heisenberg">Werner Heisenberg</a>) genannt. In weiteren Fällen kann das Fehlverhalten subjektiv sein („das Programm ist viel zu langsam“) oder das Laufzeitverhalten hängt von unbekannten Faktoren der Hardware ab.
</p><p>Ist der Fehler analysiert beziehungsweise gefunden, muss beurteilt werden, wie er zu beheben ist. Auch das ist nicht immer einfach, denn es ist etwa möglich, dass einige Programmteile nur deshalb <i>korrekt</i> funktionieren, weil der Fehler vorhanden ist. Wenn man ihn nun behebt, können andere Funktionen plötzlich nicht mehr funktionieren. Oder es stellt sich heraus, dass der Fehler Folge eines <a href="Softwarearchitektur" title="Softwarearchitektur">Designfehlers</a> ist, also bei der Entwicklung komplett vergessen wurde, dass die zum Fehler führende Situation überhaupt auftreten kann. In solchen Fällen kann die Behebung sehr viel Zeit in Anspruch nehmen oder man entscheidet sich gar dafür, den Fehler nicht zu beheben, weil das Risiko, dadurch mehr Schaden anzurichten als Nutzen, zu groß ist.
</p><p>Debuggen gilt als komplizierter als Programmieren und kann daher wesentlich mehr Zeit in Anspruch nehmen als Programmieren. Darum wird empfohlen, leicht lesbaren Code zu schreiben.<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup>
</p>
<div class="mw-heading mw-heading2"><h2 id="Techniken">Techniken</h2></div>
<p>Weil das Feld der möglichen Softwareprobleme sehr groß ist, gibt es auch vielfältige Möglichkeiten, sie zu analysieren. Zunächst werden die Möglichkeiten für die Analyse von „klassischen“ Bugs aufgezeigt, also solchen, bei denen ein Ergebnis offensichtlich falsch ist oder das Programm reproduzierbar bei einer bestimmten Eingabe <a href="Programmabsturz" class="mw-redirect" title="Programmabsturz">abstürzt</a>. <a href="Eingabe_und_Ausgabe" title="Eingabe und Ausgabe">Eingabe und Ausgabe</a> müssen sich dabei aber nicht auf Tastatur oder Bildschirm beschränken, sondern es sind darunter alle möglichen Datenein- und Ausgänge zu verstehen (Dateien, Netzwerkverbindungen, Drucker, Scanner etc.).
</p><p>Der primitivste Ansatz, der allerdings auch nur bei klassischen Bugs funktioniert, ist, das Programm mit zusätzlichen Ausgaben zu <i>instrumentieren</i>. Es werden also Programmzeilen hinzugefügt, die Zwischenergebnisse ausgeben, entweder auf den Bildschirm oder in eine <a href="Logdatei" title="Logdatei">Logdatei</a>. So kann herausgefunden werden, in welchem Schritt einer Berechnung ein Problem auftaucht, oder an welcher Stelle das Programm unerwartet abbricht. Man kann dabei eine <a href="Divide-and-Conquer" class="mw-redirect" title="Divide-and-Conquer">Divide-and-Conquer</a>-Taktik oder eine <a href="Bin%C3%A4re_Suche" title="Binäre Suche">Binäre Suche</a> anwenden, um das Problem einzugrenzen. Diese Art der Fehlersuche wird manchmal auch <i>printf-Debugging</i> genannt, in Anlehnung an die <a href="C_(Programmiersprache)" title="C (Programmiersprache)">C-Funktion</a> <a href="Printf" title="Printf">printf</a>, die dafür häufig benutzt wird.
</p><p>Sobald die Programme komplexer werden, kommt zur Suche klassischer Fehler meistens ein eigentlicher <a href="Debugger" title="Debugger">Debugger</a> zur Anwendung. Ein moderner Debugger ist häufig Teil einer <a href="Integrierte_Entwicklungsumgebung" title="Integrierte Entwicklungsumgebung">IDE</a>, in der auch das Programm entwickelt wurde. Der Programmierer kann direkt im <a href="Quelltext" title="Quelltext">Quelltext</a> sogenannte <a href="Haltepunkt_(Programmierung)" title="Haltepunkt (Programmierung)">Breakpoints</a> setzen, die das Programm unterbrechen. Wenn das Programm unterbrochen ist, kann der Zustand überprüft werden, in dem der <a href="Aufrufstapel" title="Aufrufstapel">Aufrufstapel</a> untersucht oder <a href="Variable_(Programmierung)" title="Variable (Programmierung)">Variablen</a> überprüft werden. Das Programm kann auch Zeile für Zeile ausgeführt werden, um schnell unerwartete <a href="Sprunganweisung" title="Sprunganweisung">Sprünge</a> zu finden. Der Debugger ist heute neben dem <a href="Compiler" title="Compiler">Compiler</a> das wichtigste Werkzeug eines <a href="Programmierer" class="mw-redirect" title="Programmierer">Programmierers</a>.
</p><p>Im Gegensatz dazu unterbricht ein Tracer zur <a href="Ablaufverfolgung" title="Ablaufverfolgung">Ablaufverfolgung</a> die Programmausführung nicht, sondern zeichnet währenddessen Informationen über Ablauf und Variablenwerte auf, die der Programmierer im Nachhinein auswertet. Die Ablaufverfolgungspunkte (engl. tracepoints) können vom Programmierer im Quelltext gesetzt werden oder generisch definiert sein, zum Beispiel bei jedem Funktionsaufruf oder jeder Zeile.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>
</p><p>Mittels Logdateien oder <a href="Crash_Dump" class="mw-redirect" title="Crash Dump">Crash Dumps</a> ist es manchmal möglich, die Ursache eines Fehlers zu finden, obwohl das Programm bereits abgestürzt ist und obwohl der Fehler nicht einfach reproduzierbar ist oder der Pfad, der zum Fehler führte, nicht bekannt ist.<sup id="cite_ref-10" class="reference"><a href="#cite_note-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup> Der gespeicherte <a href="Aufrufstapel" title="Aufrufstapel">Aufrufstapel</a> zusammen mit der <a href="Exception" class="mw-redirect" title="Exception">Exception</a> können einen hinreichenden Hinweis darüber geben, welche <a href="Invariante_(Informatik)" title="Invariante (Informatik)">Invariante</a> nicht erfüllt war oder welche Operation unerwartete Ergebnisse lieferte.
</p><p>Ein <a href="Profiler_(Programmierung)" title="Profiler (Programmierung)">Profiler</a> ist ein Computerprogramm, das ein zu untersuchendes Programm während des Ausführens analysiert und Informationen darüber liefert, welche Funktionen im Programm wie viel Zeit – meist relativ zur insgesamt verbrauchten Zeit – verwendet. So kann herausgefunden werden, welche Operationen länger dauern als nötig oder wo sich eine <a href="Optimierung" class="mw-redirect" title="Optimierung">Optimierung</a> lohnt. Es ist weder möglich noch sinnvoll, bereits bei der Entwicklung alle möglichen Optimierungsschritte einzubauen, weil erst beim Testen klar wird, welche Funktionen wie oft ausgeführt werden und wo eine Verzögerung stört. Alternativ kann mit den gleichen Tools oft auch der Speicherverbrauch untersucht werden.
</p>
<div class="mw-heading mw-heading2"><h2 id="Gegenmaßnahmen"><span id="Gegenma.C3.9Fnahmen"></span>Gegenmaßnahmen</h2></div>
<p>Mit einem Debugger ist es grundsätzlich auch möglich, Programme zu untersuchen, die man nicht selber geschrieben hat oder zu denen man den <a href="Quelltext" title="Quelltext">Quelltext</a> nicht besitzt. Letzteres erschwert die Sache zwar wesentlich, macht die Untersuchung aber nicht unmöglich. Der Zweck solcher Operationen ist oft illegal oder unstatthaft: Es wird etwa versucht, die Funktionsweise von Algorithmen zu analysieren, um sie in eigenen Programmen verwenden zu können oder es wird eine Lizenzabfrage („<a href="Kopierschutz" title="Kopierschutz">Kopierschutz</a>“) umgangen oder ausgebaut.<sup id="cite_ref-soft-prot_11-0" class="reference"><a href="#cite_note-soft-prot-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup> Bei (Mehrspieler-)Computerspielen wird zuweilen versucht zu betrügen, indem das Programm manipuliert wird, etwa um Gegner durch Wände hindurch sehen zu können oder so, dass die eigene Spielfigur bei einem Treffer keinen Schaden erleidet. Maßnahmen, die dies verhindern sollen, werden Anti-Debugging-Methoden genannt.<sup id="cite_ref-veracode-antidebugging_12-0" class="reference"><a href="#cite_note-veracode-antidebugging-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup>
</p><p>Um solche Angriffe zu detektieren, kann ein Programm versuchen, die Präsenz eines Debuggers zu ermitteln.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup> Ein guter Debugger ist jedoch für das Programm möglichst transparent, denn im Normalfall soll durch das Debuggen die Funktion des Programms nicht verändert werden. Ganz verhindern lassen sich <a href="Hacker" title="Hacker">Hackerangriffe</a> damit also nicht – unter dem Strich ist es eine Abwägung, den Aufwand für die Sicherung des Programms ins Verhältnis zu stellen mit dem geschätzten Aufwand, den ein Hacker hätte, die Maßnahmen zu umgehen, sowie dem damit eventuell einhergehenden wirtschaftlichen Nachteil. Auch muss die Anti-Debugging-Maßnahme geeignet sein, das illegitime Verfahren zu vermeiden oder zu verhindern. Das Prinzip, die Funktionsweise und den Quelltext geheim zu halten, um beispielsweise das Ausnutzen von Sicherheitslücken zu erschweren, wird als <a href="Security_through_obscurity" title="Security through obscurity">Security through obscurity</a> bezeichnet und ist in der Fachwelt umstritten.
</p>
<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>
<ul><li>Michaeli, Tilman. Debugging im Informatikunterricht (2021). <a href="Digital_Object_Identifier" title="Digital Object Identifier">doi</a>:<span class="uri-handle" style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://doi.org/10.17169/refubium-28811">10.17169/refubium-28811</a></span></li></ul>
<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>
<ol class="references">
<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text">Herbert Bernstein: <cite style="font-style:italic">Mikrocontrollerprogrammierung in Assembler und C</cite>. ISBN 978-3-8266-8313-8, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>67</span>.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Debuggen&rft.au=Herbert+Bernstein&rft.btitle=Mikrocontrollerprogrammierung+in+Assembler+und+C&rft.genre=book&rft.isbn=9783826683138&rft.pages=67" style="display:none"> </span></span>
</li>
<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text">Johannes Brauer: <cite style="font-style:italic">Grundkurs Smalltalk. Objektorientierung von Anfang an</cite>. ISBN 978-3-663-12151-0, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>59</span>.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Debuggen&rft.au=Johannes+Brauer&rft.btitle=Grundkurs+Smalltalk.+Objektorientierung+von+Anfang+an&rft.genre=book&rft.isbn=9783663121510&rft.pages=59" style="display:none"> </span></span>
</li>
<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text">Alexander Schill, Thomas Springer: <cite style="font-style:italic">Verteilte Systeme. Grundlagen und Basistechnologien</cite>. 2012, ISBN 978-3-642-25796-4, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>217</span>.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Debuggen&rft.au=Alexander+Schill%2C+Thomas+Springer&rft.btitle=Verteilte+Systeme.+Grundlagen+und+Basistechnologien&rft.date=2012&rft.genre=book&rft.isbn=9783642257964&rft.pages=217" style="display:none"> </span></span>
</li>
<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text">Michaeli, Tilman. Debugging Im Informatikunterricht (2021). <a href="Digital_Object_Identifier" title="Digital Object Identifier">doi</a>:<span class="uri-handle" style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://doi.org/10.17169/refubium-28811">10.17169/refubium-28811</a></span>, Seite 20. Zitiert aus ISO, IEC (2010). „IEEE, Systems and Software Engineering–Vocabulary“. In: IEEE computer society, Piscataway, NJ 8, S. 9.</span>
</li>
<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text">Michaeli, Tilman. Debugging Im Informatikunterricht (2021). Seite 22f.</span>
</li>
<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text">Brian W. Kernighan, P.J. Plauger: <cite class="lang" lang="en" dir="auto" style="font-style:italic">The elements of programming style</cite>. Hrsg.: Yourdon. 2. Auflage. McGraw-Hill, New York 1978, ISBN 0-07-034207-5, 2 Expression, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>10</span> (englisch, 168 S.): <span class="lang" lang="en" dir="auto">“The problem with obscure code is that debugging and modification become much more difficult, and these are already the hardest aspects of computer programming.Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”</span><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Debuggen&rft.atitle=2+Expression&rft.au=Brian+W.+Kernighan%2C+P.J.+Plauger&rft.btitle=The+elements+of+programming+style&rft.date=1978&rft.edition=2&rft.genre=bookitem&rft.isbn=0070342075&rft.pages=10&rft.place=New+York&rft.pub=McGraw-Hill" style="display:none"> </span></span>
</li>
<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html#Tracepoints"><i>Tracepoints (Debugging with GDB).</i></a><span class="Abrufdatum"> Abgerufen am 24. Juni 2022</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=Tracepoints+%28Debugging+with+GDB%29&rft.description=Tracepoints+%28Debugging+with+GDB%29&rft.identifier=https%3A%2F%2Fsourceware.org%2Fgdb%2Fonlinedocs%2Fgdb%2FTracepoints.html%23Tracepoints"> </span></span>
</li>
<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text"><span class="cite">Sagar-S-S: <a rel="nofollow" class="external text" href="https://docs.microsoft.com/de-de/visualstudio/debugger/using-tracepoints"><i>Protokollieren von Informationen mit Ablaufverfolgungspunkten - Visual Studio (Windows).</i></a><span class="Abrufdatum"> Abgerufen am 24. Juni 2022</span> (deutsch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=Protokollieren+von+Informationen+mit+Ablaufverfolgungspunkten+-+Visual+Studio+%28Windows%29&rft.description=Protokollieren+von+Informationen+mit+Ablaufverfolgungspunkten+-+Visual+Studio+%28Windows%29&rft.identifier=https%3A%2F%2Fdocs.microsoft.com%2Fde-de%2Fvisualstudio%2Fdebugger%2Fusing-tracepoints&rft.creator=Sagar-S-S&rft.language=de-de"> </span></span>
</li>
<li id="cite_note-9"><span class="mw-cite-backlink"><a href="#cite_ref-9">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.c64-wiki.de/wiki/TRON"><i>TRON – C64-Wiki.</i></a><span class="Abrufdatum"> Abgerufen am 24. Juni 2022</span>: „Der Befehl TRON (engl. TRace ON) schaltet die Programmablaufverfolgung (engl. Tracing) ein.“</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=TRON+%E2%80%93+C64-Wiki&rft.description=TRON+%E2%80%93+C64-Wiki&rft.identifier=https%3A%2F%2Fwww.c64-wiki.de%2Fwiki%2FTRON"> </span></span>
</li>
<li id="cite_note-10"><span class="mw-cite-backlink"><a href="#cite_ref-10">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.drdobbs.com/tools/postmortem-debugging/185300443"><i>Postmortem Debugging.</i></a><span class="Abrufdatum" style="display:none"> Abgerufen im 1. Januar 1</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=Postmortem+Debugging&rft.description=Postmortem+Debugging&rft.identifier=&rft.date=&rft.language=en"> </span></span>
</li>
<li id="cite_note-soft-prot-11"><span class="mw-cite-backlink"><a href="#cite_ref-soft-prot_11-0">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20111001172453/http://people.seas.harvard.edu/~mgagnon/software_protection_through_anti_debugging.pdf"><i>Software Protection through Anti-Debugging Michael N Gagnon, Stephen Taylor, Anup Ghosh.</i></a> Archiviert vom <style data-mw-deduplicate="TemplateStyles:r250917974">
/* start https://de.wikipedia.org/ */
.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}
/* end https://de.wikipedia.org/ */
</style><span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=http%3A%2F%2Fpeople.seas.harvard.edu%2F%7Emgagnon%2Fsoftware_protection_through_anti_debugging.pdf">Original</a></span> am <span style="white-space:nowrap;">1. Oktober 2011</span><span>;</span><span class="Abrufdatum"> abgerufen am 25. Oktober 2010</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=Software+Protection+through+Anti-Debugging+Michael+N+Gagnon%2C+Stephen+Taylor%2C+Anup+Ghosh&rft.description=Software+Protection+through+Anti-Debugging+Michael+N+Gagnon%2C+Stephen+Taylor%2C+Anup+Ghosh&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20111001172453%2Fhttp%3A%2F%2Fpeople.seas.harvard.edu%2F%7Emgagnon%2Fsoftware_protection_through_anti_debugging.pdf&rft.date=&rft.source=http://people.seas.harvard.edu/~mgagnon/software_protection_through_anti_debugging.pdf&rft.language=en"> </span></span>
</li>
<li id="cite_note-veracode-antidebugging-12"><span class="mw-cite-backlink"><a href="#cite_ref-veracode-antidebugging_12-0">↑</a></span> <span class="reference-text"><span class="cite">Tyler Shields: <a rel="nofollow" class="external text" href="https://www.veracode.com/blog/2008/12/anti-debugging-series-part-i"><i>Anti-Debugging Series – Part I.</i></a> In: <i>Veracode.</i> 2. Dezember 2008,<span class="Abrufdatum"> abgerufen am 17. März 2009</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=Anti-Debugging+Series+%E2%80%93+Part+I&rft.description=Anti-Debugging+Series+%E2%80%93+Part+I&rft.identifier=&rft.creator=Tyler%26%2332%3BShields&rft.date=2008-12-02&rft.language=en"> </span></span>
</li>
<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.deepinstinct.com/2017/12/27/common-anti-debugging-techniques-in-the-malware-landscape/"><i>Common Anti-Debugging Techniques in the Malware Landscape.</i></a> 27. Dezember 2017,<span class="Abrufdatum"> abgerufen am 10. Juli 2021</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ADebuggen&rft.title=Common+Anti-Debugging+Techniques+in+the+Malware+Landscape&rft.description=Common+Anti-Debugging+Techniques+in+the+Malware+Landscape&rft.identifier=&rft.date=2017-12-27&rft.language=en"> </span></span>
</li>
</ol></div><!--htdig_noindex--><div><div class="zim-footer">
Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-12-11" href="https://de.wikipedia.org/wiki/?title=Debuggen&oldid=262311525">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.
</div>
</div><!--/htdig_noindex--></div>
</div>
</main>
</div>
</div>
</div>
<script src="./_webp_/webpHandler.js"></script>
</body></html>